Acorn Risc Technologies StrongARM CD-ROM/Acorn Risc Technologies StrongARM CD-ROM.iso/ftp/documents/appnotes/231_245/231c/Text

Text File | 1994-01-10 | 21.5 KB | 535 lines

-----------------------------------------------------------------------------
2nd August 1993
-----------------------------------------------------------------------------
Support Group Application Note
Number: 231
Issue:  Optimisting AUN Network performance
Author: Carl Sellers
-----------------------------------------------------------------------------



-----------------------------------------------------------------------------
Applicable Hardware:

Related Application Notes:


-----------------------------------------------------------------------------
Copyright (C) Acorn Computers Limited 1992

Every effort has been made to ensure that the information in this leaflet is
true and correct at the time of printing. However, the products described in
this leaflet are subject to continuous development and improvements and
Acorn Computers Limited reserves the right to change its specifications at
any time. Acorn Computers Limited cannot accept liability for any loss or
damage arising from the use of any information or particulars in this
leaflet. ACORN, ECONET and ARCHIMEDES are trademarks of Acorn Computers
Limited.
-----------------------------------------------------------------------------
Support Group
Acorn Computers Limited
Acorn House
Vision Park
Histon
Cambridge
CB4 4AE
-----------------------------------------------------------------------------

Optimising AUN Network performance


This document is intended to assist network managers who have either
recently installed, or upgraded to, the AUN/Level 4 Fileserver software. It
will deal with aspects of the fileserver installation which directly effect
the performance of the network.

It is, however, beyond the scope of this document to cover all aspects of
Ethernet design and installation. Those readers who seek information on more
complex network topologies should refer, in the first instance, to the
documentation supplied with the AUN/Level 4 Fileserver.

Applicable Hardware:  All RISC OS based Level 4 Fileservers, version 1.10 or
above.

Related Application Notes:  Purchase and Installation of a simple AUN
Network.


1   Introduction
This note is intended to accompany the application note Purchase and
Installation of a simple AUN Network.  It is targeted at those who have a
little experience in the day to day running of an AUN/Level 4  network and
are now seeking to optimise its performance.  Some of the advice given here
is valid for all network types,  but the emphasis is on Ethernet, AUN
networks. Much of this information is available in the Level 4 Managers
Guide and the AUN Mangers Guide, but is reproduced here.

2   Disc Management and directory structure
To make best use of the available space on the hard disc of the fileserver,
it is often advisable to format the hard disc with a small "LFAU" or Large
File Allocation Unit size. This is because each time a directory is created,
there is a minimum size allocated to the directory and its contents. If this
minimum size is rather large, and there are very large numbers of rather
empty directories on the fileserver disc, then much space on the fileserver
can be lost.

Consider the following situation:

A school has decided a policy of giving each student an area on the network
for the duration of their time at the school.  The school has a 5 year
intake with approximately 200 students in each year. The network manager
therefore creates a 1000 user accounts with the directory structure shown
below:

(See Graphic No.1)

Figure 1: Typical directory structure for a student in a Secondary School.

Imagine the situation where the students in the 1st and 2nd years only use
the network for saving DTP documents and so the other directories remain
empty until the 3rd year or above.

On a large disc (200 MBytes and upwards) the default LFAU may result in the
creation of directories as big as 15Kb, which although fine for the hard disc
of a standalone machine, may be far from ideal for the fileserver. The
following table lists some common values and the minimum corresponding disc
space used for each directory.

(See Graphic No.2)

Table 1: Values for the Large Allocation File Unit and the resulting directory size.

The normal default LFAU for an A5000 is 512. So, using the default directory
structure shown above, we can see that just the empty directories will
allocate 67Kb of the disc space to each student. For 1000 students this will
amount to over 65Mb of disc space.  In contrast, a disc with a LFAU of 256
would only require 33Mb  of disc space in order to store the same directory
structure.

On the Level4 Fileserver disc there is a program Read_LFAU which enables you
to interrogate the disc for information about the size of its LFAU. If this
is large, and the difference between counting all files and the free space
on the disc is significant, you may choose to reformat the disc at an
appropriate time with a smaller (say 256) LFAU.

*****All data is lost from the disc during formatting. Ensure that you have
backed up the contents of the disc BEFORE reformatting any disc which
contains valuable data.******

It is important to remember that small files are stored in the sectors
allocated to the directory structure so all the space is not "lost".
However, it is important to remember that the size of the LFAU is a
compromise between disc storage space and the file retrieval speed. You may
wish to experiment with different LFAU values before transferring all the
data onto the disc, although generally the following rules apply:

If the LFAU is large then the data transfer rate will be faster, but
slightly less data can be stored on the disc. Conversely, if the LAFU is
small then the data transfer rate will be slower, but slightly more data can
be stored on the disc.

A sensible directory structure is essential to get the best performance out
of the fileserver. A very flat, or an excessively deep structure is not
recommended. Keep popular applications near the root of the fileserver with
less popular ones further down and with little used reference material
tucked further down still. Level 4 gives you the ability to export multiple
discs, and also to export a disc from any point on its directory structure.
This is very useful because it is then possible to keep information that is
private to the fileserver out of reach of the normal network user.

Look at the example directory structure shown overleaf. Note that the number
of objects in the exported Root ($) directory is kept reasonably small.
Under no circumstances should you exceed 77 objects in this Root directory,
and about half this is probably a good maximum. Note the !Armboot
application in the exported root (Network). This is the boot sequence used
by the Boot user. If you have all RISC OS 3 machines, do not use the general
purpose !ArmBoot application that is supplied with the Level 4 Fileserver as
this is intended for a mixture of RISC OS 2 and RISC OS 3 machines and
consequently contains a number of compromises. A different style boot
sequence is required for RISC OS 3 to prevent stations running applications,
such as !System and !Fonts, twice; once during during the boot sequence and
a second time as soon as a directory window that contains them is opened.
The example given in application note 228, Purchase and Installation of a
simple AUN Network, is a good starting point, and it is advised that you
observe what happens when a station is booted by looking at the server
status window during this time in order to check that no redundant
operations are taking place.

 With a large !Fonts directory, much time is taken in the station
establishing all the fonts available to it, so keep these to a reasonable
minimum, (say 3 or 4) and put all the remainder in !Fonts1 as supplied with
Level 4. Worthwhile improvements can be obtained at boot time by sensible
use of the SaveFontCache and LoadFontCache commands. These commands, as
their names suggest, save and load the font cache. To use them simply allow
a machine which is logged on as Syst to see the required !Fonts. Press F12
and then issue the following commands at the * prompt:

(See Graphic No.3)

*SaveFontCache Net:$.Arthurlib.FontCache
*Access Net:$.Arthurlib.FontCache WR/r

This will save the machine's font cache into the Arthurlib directory and set
its access rights for use by any machine on the network.

To use the saved cache simply include the following command immediately
before any commands to Filer_Boot or Filer_Run the !Fonts application:

     *LoadFontCache Net:$.Arthurlib.FontCache

thereby saving the machine the job of interrogating the font path when the
machine is switched on.

When a station has been switched on and has booted itself from the network,
it is then ready to be used by a user (client). In this state it is pointing
into the exported root, with access to objects that have public read access
(WR/R) only. Level 4 supports the concept of "Hidden objects". This is where
objects can simply be hidden from other users by setting their access
attributes to LWR/. If "Hidden objects" is switched on (see Section 8) then
only objects with public read access (WR/R) will appear in the directory
viewer.

A user coming up to the machine can then log onto the fileserver in one of
two ways:

     •  as a group user such as "Geography" or "Year5"

     • by his or her private account.

Once they have logged onto the fileserver they are free to load any
application or file which has public read access or which is in their own
URD.

*****Note: In the directory structure shown above you should not have a user
"Form1" if there are personal accounts, such as Abbott and Black, below this
point. The existence of such a user can seriously compromise the security of
the network as this user will have access to all the individuals' data
directly below that point! ******

3   Armboot & Scrap files
The safest approach to scrap files is to place a copy of !Scrap in each URD.
Some applications, such as !Printers, insist on the presence of a !Scrap
application before they will install themselves on the icon bar. !Scrap
forms the repository for temporary data which is created while printing or
when data is being transferred between applications.

For the technically minded here is a brief  overview of what happens when
!Scrap is run by a machine:

     • a number of system variables are set which point to that particular
       !Scrap application.

     • if the machine is not on a network it will create a directory called
       ScrapDir inside !Scrap.

     • the machine, if it is on a network, will create a Stnxxx!yyy
       directory inside !Scrap.
       Where:         xxx is the network number.
                      yyy is the number of the creating station.

In a network environment the inclusion of the network and station number
ensure that the directory is unique, because these always combine to form
unique numbers. This ensures that the integrity of the users scrap files is
always maintained.  If you look inside a !Scrap application that has been
accessed over the network  you will see the scrap directories created there
by each station.

Opening directory viewers when a user logs on is a useful and powerful thing
to do. It saves the user wasting network bandwidth by searching through the
directory structure for his or her applications. To do this, use !Edit to
create an Obey file.  A line such as:

Filer_OpenDir Net::MYSERVER.$.Apps

will open a viewer into Apps.  Note that no reference is made to the export
mount point as this is quite invisible to the network user.

4   Loading applications & AppFS
Application loading is probably the most testing activity of a network,
especially if a whole class attempts to load an application at once. The
Broadcast Loader is not effective with Ethernet, as it chops up packets into
small ones to enable more clients to participate in the broadcast activity.
This dramatically reduces throughput on an Ethernet network and is the
reason for the recommendation that you *Unplug the Broadcast Loader in the
!ArmBoot file which is accessed by the Boot user.

There are third party solutions to the problems of loading applications, one
very effective method is used by AppFS that is marketed by AngelSoft. This
read-only filing system uses the buffering and cacheing provided by the
filecore filing system to access the disc remotely over the network. A hard
disc is required for the exclusive use of AppFS, which can then attached to
the fileserver, or indeed any other machine on the network. As AppFS is
read-only, it can rely on the fact that no data will change on the disc, and
therefore many of the problems associated with cacheing information over the
network are dispensed with. AppFS provides the following benefits:

         • reduces the network traffic considerably, by only asking for file
           information once.

         • reads data in large chunks which allows Ethernet to operate as
           efficiently as possible.

         • it speeds up application loading time over the network by a
           factor of five or more.

         • frees the fileserver to do what it does best: handling secure
           user data.

5   Gateways, bridges and repeaters
Application note 228, Purchase and Installation of a simple AUN Network,
mentioned the numbers of stations and permissible segment lengths of
Ethernet. To enable  more stations to be used or longer lengths to be
spanned then a means of joining bits of Ethernet together is required.

The AUN guide recommends that the network is arranged in clusters, with
departmental servers supplying data to stations in its domain.  The stations
in each departments domain will also require access to data on other
fileservers on the network.

The use of the !Gateway application running on a machine (usually the server
machine) provides a cost effective means of achieving this. Using such a
Gateway, will:

       • allow a maximum of two different networks to be linked together.

       • provide a very cost effective solution.

       • require no additional hardware apart from a second network
         interface.

       • ensure that network traffic is kept off the "Backbone".

Gateways do pose an overhead, and you should not consider a network where
the data ever has to cross more than two Gateways to reach its destination.

A Bridge is the next type of network interconnector. These commercially
available devices:

       • are usually quite expensive (circa £1500).

       • have built in intelligence that "learns" where destination stations
         live.

       • only pass information over the Bridge where necessary.

       • only bridge between two networks.

A Repeater, often in the form of a "Multiport Repeater" will:

       • join together a number of Ethernet segments

       • only act as a signal amplifier

       • ensure that signals emanating from one network get repeated on all
         connected networks.

       • acts as a way of extending the network,

       • not confine traffic to a particular part of the network.

Repeaters are not a low cost solution, a good multiport repeater costs
around £1000.

*****Note: There are very specific rules governing the use of Repeaters,
Bridges and Gateways which are beyond the scope of this document. You are
strongly advised to seek professional help if any of these components are
required in an installation.******

6   User management
 A large institution may have well in excess of 1000 users, each with their
own account. It is not recommended to try to give each user a simple user
name because it becomes increasingly difficult to separate out popular names
such as Smith when many may exist.  It is much easier to give users a name
which identifies their position in the establishment, for example
Year8.SmithPJ or Staff.ATeacher.

A fileserver which is structured using this technique:

        • makes finding users easier.

        • is easy to understand.

        • allows the fileserver to mirror the hierarchy of the
          establishment.

Such direct mapping is not the ideal solution in some circumstances. It may
be that the user root directory needs to be further down the directory tree
such as:

$.Users.Year8.SmithPJ

or possibly that the user root directory needs a completely different
mapping so that user Year8.SmithPJ would have a URD of say:

$.Users.Girls.Form3.SmithPJ

It is possible, but perhaps a little tedious to manage such a mapping using
!Manager. Recent third party products, such as !NetManage from Suitable
Software, provide access to full global user profile management facilities,
via the desktop.  The facilities provided by !NetManage  include:

       • the selection of a group of user profiles which can then be
         updated, removed or deleted.

       • batch creation of user profiles via text or CSV files.

       • the ability to create user root directories matching predefined
          directory structures.

       • user icons that be dragged between fileservers to provide true copy
         and move operations.

7   CD ROMs on the network
Level 4 has the ability to export any filing system that has been attached
to the server machine, and this of course includes CD ROM.  CD ROM differs
from many filing systems in that although data can be read from the media
quite quickly once the drives read head is in the correct position, it takes
a long time to search for the start of the required data. This means that
although performance may be satisfactory on a local disc when accessed by a
single user, it becomes much slower when used simultaneously by a number of
users over the network. This is because the read head of the drive is moving
constantly between areas of the disc in an attempt to be "fair" to all
users.

The issue of networking CD ROM is currently under investigation by Acorn,
and it is hoped that Acorn will be in a position to announce improvements in
this area in the future.

For some data, such as clip art and encyclopaedic information that is
accessed relatively infrequently, CD ROM provides a viable service on the
network. For application loading it usually fails to meet the requirements
of a classroom situation. It is not yet possible to guarantee the integrity
of single (let alone multiple!)  moving video sessions from applications
such as Replay over the network.

8   Hidden objects
This is a powerful feature of Level 4 that was designed as a security
enhancement but can also be used to good effect when an increase in network
performance is required. By enabling this feature from the Level 4 icon on
the Icon bar, all files,  directories and applications that the user has no
right to use fail to appear in the directory window. This is achieved by
removing public read access to applications that are not in regular use. As
applications take some time to load into directory viewers, the use of this
technique will ensure that the windows open faster, and that less traffic
appears on the network.

9   Automatic log on The Level 4 fileserver disc contains an example, in
Extras.AutoBoot, of how to configure the system so that when a machine is
switched on it logs onto the fileserver as a particular user. This is
especially useful in institutions where a particular machine always has the
same user(s) on it, such as many primary school classrooms. It has the
benefit that no time is lost between the user arriving at the machine and
being able to use it, as it will (assuming that it has been powered up) be
waiting, with perhaps the application and work directories displayed, ready
for the user.

This approach, coupled with staggering the time that machines are switched
on, may prove to be useful in reducing the perceived natural delays that
occur on any network.

10   Server Mode and type
Although this has been covered in application note 228, Purchase and
Installation of a simple AUN Network it is worth mentioning again. For best
performance run the Server machine in Standalone mode, ie by starting Level4
rather than !Server on start up. As this prevents multitasking from taking
place, this mode of operation cannot be used if other applications such as
!Spooler or !AppServer is also required to be run on the same machine. In
this case, ensure that a low resolution screen mode is used such as Mode 0,
and that the status window is not open. Do not use the log file facilities
unless you have a genuine reason for recording transactions.

If you are using an ADFS hard disc (which includes the IDE drive of A5000s)
then you should ensure that the ADFS cache is enabled, by using the
configure commands:

*Co. ADFSDirCache 64K
*Co. ADFSBuffers 128

With SCSI drives on a machine fitted with an Acorn SCSI card, a suitable
command would be:

*Co. SCSIFS DirCache 128K

And with CD ROMS:

*Co. CDROMBuffers 128K

A fileserver machine with an ARM3 processor such as an A5000 will give much
more throughput on the network than one with an ARM2.  The amount of memory
available to the server is not particularly relevant, more than 2Mb will not
actually help. Clearly a fast SCSI device will pay dividends, and it is
worth investing in a high performance drive when considering adding drives
to the fileserver.

Appendix A: Useful Addresses

AppFS is available from:

Angelsoft Educational
35 Heol Nant
Swiss Valley
Llanelli
SA14 8EN


Tel [phone]

NetManage is available from:

Suitable Software
136 Carter Street
Fordham
Ely
Cambridgeshire
CB7 5JU

Tel [phone]

Other network related products are also available from:
XOB
Balkeerie
Eassie by Forfar
Angus
DD8 1SR


Tel [phone]

NetGain is available from:

Digital Services Limited
9 Wayte Street
Cosham
Portsmouth
Hants
PO6 3BS

Tel [phone]

Network Supervisor is available from:
AU Enterproses Ltd
126 Great North Road
Hatfield
Herts AL9 5JZ



Tel [phone]
Fax [phone]